In a software solution deal between two stakeholders, one stakeholder (e.g. a software solutions customer) acquires developed software from a second stakeholder (e.g. a software solutions vendor). However, many a times, the vendor may disallow access to a source code of a software product and share only the binary/executable version of the software product. The customer may want to find any security threats associated with the software before deploying it. Existing security analysis techniques include finding possible security threats by analyzing the source code. If the source code is not available, an executable version of the software may be reverse engineered to write a speculated version of the source code according to existing security analysis techniques. The outcome of security analysis of the reverse engineered code may deviate from the actual security issues associated with the source code because the reverse engineered code may not be an exact replica of the source code.
The security analysis of the reverse engineered code may indicate broad level security aspects such as the source code is functionally correct or the software is performing appropriately etc. However, security analysis of the reverse engineered code may not be able to indicate all the actual possible security threats associated with the source code. For example, the source code may have been written in a non-secure way thus making it non-compliant with some security standards. Here, although the security analysis of the reverse engineered code may indicate that the reverse engineered code is functionally correct, it may not indicate all the specific security issues associated with the source code. This makes the software vulnerable to security threats when deployed.
Therefore, there is a need for a security analysis technique that accurately performs the security analysis of a software product when the source code is not available.
The present invention is directed to overcoming these and other deficiencies in the art.